<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
		<title>Introduction</title>
		<link type="text/css" rel="stylesheet" href="PLUGINS_ROOT/org.polarsys.capella.doc/html/styles.css"/>
	</head>
	<body>
		<h1 id="Introduction">Introduction</h1>
		<h2 id="Why_Data_Modeling.3F">Why Data Modeling?</h2>
		<p>A significant part of system engineering consists in ensuring proper definition and coherency between data &amp; information inside the system, and those exchanged with external actors (including interface &amp; I/O management).</p>
		<p>In order to describe un-ambiguously what is exchanged between functions, activities, components, and external actors, a specific formalization of data, information, material flow… used in the system is usually performed.</p>
		<p>Beyond this description need, one important engineering task consists in avoiding multiple definitions of a same data in different places of the system. Hence the need to indicate that several exchanges should carry the same kind of data, without having to re-define these common data for each exchange.</p>
		<p>Rationalizing and mastering data definition and use is a major stake of engineering;</p>
		<ul>
			<li>to structure them in an intelligible manner, reducing complexity of their definition and use,</li>
			<li>to bring out a semantics coherency, independently from their use – or common to all their uses,</li>
			<li>to avoid ambiguity, redundancy, incoherency in their different uses.</li>
		</ul>
		<p>The main benefits derived from this improved data definition are:</p>
		<ul>
			<li>better consistency and completeness of component interfaces,</li>
			<li>detection of hidden dependencies between components (for instance when the same piece of data is produced or consumed by several components),</li>
			<li>global architecture optimization (to remove dependencies),</li>
			<li>less rework during IVVQ,</li>
			<li>easier impact analysis in the case of engineering evolutions.</li>
		</ul>
		<p>An efficient means to ensure these properties is to formalize a ‘data model’ (also known as ‘information model’ in information processing dominant systems), describing the kind of data to be used by the system; at least, for each kind of data:</p>
		<ul>
			<li>data name and semantics,</li>
			<li>their definition, contents and properties (unit, value domain…),</li>
			<li>their relationships with other data (‘is composed of’, ‘is kind of’, ‘uses’, semantic reference …)</li>
		</ul>
		<h2 id="Main_Concepts_Overview">Main Concepts Overview</h2>
		<p>Interfaces, Exchanges and Exchange Items are contracts specifying how components can interact with each other. Exchange Items specify the communications between components and Interfaces or Exchanges allow structuring these communications. Interfaces and/or Exchanges are defined by grouping (referencing) Exchange Items: they can share Exchange Items definitions.</p>
		<p>An [ Exchange Item] defines a communication media and a set of Data semantically coherent with regards to their usage in a given context:</p>
		<ul>
			<li>same communication principles</li>
			<li>simultaneity of transportation</li>
			<li>same non functional properties (e.g. security level, integrity requirement, expected performance...)</li>
			<li>indivisibility (an Exchange Item is atomic)</li>
		</ul>
		<p>Possible communication mechanisms for Exchange Items are: OPERATION, EVENT, FLOW, and SHARED DATA.</p>
		<p>Exchange Items are structured through Exchange Items Elements in the same way as classes are structured in Properties. These elements are in turn defined by classes, complex types and simple types.</p>
		<p><center>
			<img border="0" src="Images/image001.png"/></center>
		</p>
		<p><center>
			<img border="0" src="Images/image002.jpg"/></center>
		</p>
		<p>Definitions of Interfaces, Exchange Items, Exchange Item Elements and Types, are mostly done in Capella through Class Diagrams. These CDBs (Class Diagram Blank) are available at each Arcadia abstraction level, and can be found under the 
			<i>Transverse Modeling</i> topic.
		</p>
		<p><center>
			<img border="0" src="Images/image003.jpg"/></center>
		</p>
	</body>
</html>